This is preperation for refactoring the files so that there are sansio
and flask specific versions. This structure follows the Werkzeug
structure/pattern.

This follows a similar structure in Werkzeug and allows for async
based IO projects, specifically Quart, to base themselves on
Flask.

Note that the globals, and signals are specific to Flask and hence
specific to Flask's IO. This means they cannot be moved to the sansio
part of the codebase.

This allows a Blueprint implementation that has additional funcs, such
as Quart with its before_websocket_funcs (as example), to extend the
merge method to also merge these functions.

This is useful as there is contextual information that could be loaded
via IO e.g. information from a database. This also matches Quart and
hence makes the shared signature easier to manage.

Whilst not strictly true for Flask, it is true for Flask and Quart and
hence makes it much easier for Quart to extend Flask classes. The
alternatives are generic usage in the sansio codebase or mixed usage
within Flask. I think this is a good compromise.

It may also be awaitable, as invocations are wrapped in ensure_sync.

This should hopefully explain what it is used for and why certain code
cannot be present in it.